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I.     INTRODUCTION 

Electronic  data  interchange  (EDI)  is  the  intercompany,  computer-to- 
computer  exchange  of  business  documents  in  standard  formats.  Through 
EDI,  such  common  business  forms  as  invoices,  bills  of  lading,  and  pur- 
chase orders  are  transformed  to  a  standard  data  format  and  electronically 
transferred  between  trading  partners. 

Electronic  Data  Interchange  (EDI)  is  fast  becoming  the  standard  way 
of  exchangeing  business  documents,  not  only  in  this  country  but  also  in 
the  rest  of  the  world.  EDI  provides  a  faster,  more  accurate,  less  costly 
method  of  communication  than  do  traditional  methods  of  business  com- 
munications such  as  mail,  telephone,  and  personal  delivery.  However, 
EDI  is  doing  more  than  just  changing  how  businesses  communicate;  it  is 
changing  the  way  businesses  operate.  Electronic  data  interchange  is 
changing  industry.  Trading  relationships  are  changing,  management 
philosophies  are  changing,  and  production  techniques  are  changing. 

The  direct  benefits  of  EDI  are  immediately  apparent  from  its  defi- 
nition: 

•  Saving:  EDI  eliminates  paper,  postage  premiums  for  overnight  de- 
livery, and  the  like.  Rooms  full  of  data  entry  personnel  and  equip- 
ment become  obsolete. 


•  Accuracy:  EDI  communication  is  direct,  instantaneous,  and  imme- 
diately verifiable.  That  means  no  more  lost  or  misrouted  mail. 
Documents  exchanged  are  100  percent  accurate  and  complete.  This 
make  such  jobs  as  reconciliation  for  payment  much  easier.  All  this 
provides  additional  savings. 

•  Speed:  Instantaneous  communication  is  an  important  EDI  benefit 
to  those  companies  that  compete  on  cycle  time.  EDI  is  essential  in 
supporting  just-in-time(JIT)  delivery  schedules. 

The  costs  and  benefits  of  incorporating  EDI  into  a  business  operation 
have  been  estimated  by  Price  Waterhous  as  follows:  For  a  typical  $10 
million  company,  the  annual  cost  EDI  costs  will  remain  fairly  steady  be- 
tween 10  and  12  million  dollars  per  year.  However,  the  annual  saving  for 
the  company  will  increase  each  year  yielding  a  total  saving  over  the  fi\3 
year  period  of  $200  million  [Ref.  1:  p.  27]. 

In  the  U.S.,  there  are  currently  about  5,000  companies  using  EDI,  and 
that  number  is  expected  to  double  annually  for  the  next  three  years.  Al- 
ready in  the  automotive,  chemical,  pharmaceutical,  and  grocery  indus- 
tries, EDI  has  become  a  prerequisite  for  doing  business  --  that  is, 
companies  not  currently  EDI  -  capable  are  suffering  a  competitive  dis- 
advantage. Several  other  industries  -  railroads,  apparel,  textile,  retail, 
electronics,  health  care  --  are  not  far  from  this  level  of  EDI  commitment. 
Growth  of  EDI  in  other  industries  will  be  rapid,  as  companies  seek  to 
leverage  their  EDI  investments  over  all  their  trading  partners.    By  1993, 


an  estimated  70  percent  of  U.S.  businesses  will  make  significant  use  of 
EDI  [Ref.  2:  p.  11]. 

EDI  use  is  spreading  internationally,  as  well.  Virtually  nonexistent  as 
little  as  two  years  ago,  the  international  EDI  market  is  blossoming- 
particularly  in  Great  Britain  and  Canada.  There  are  now  900  major 
European  companies  using  EDI  and  that  number  is  expected  to  grow  to 
140,000  by  1995.  Just  as  it  would  be  almost  unthinkable  nowadays  for  a 
business  not  to  have  a  telephone  to  communicate  with  customers  and 
suppliers,  it  may  be  almost  as  unthinkable  for  a  business  not  to  have  a 
computer  for  the  same  purpose. 


II.     EDI  DEVELOPMENT  AND  STANDARDS 

A.     OVERVIEW 

Standards  are  fundamental  to  EDI.  EDI  is  the  intercorporate  ex- 
change o\~  business  documentation  in  structured,  machine-processable 
form.  EDI  is  designed  so  that  the  receiving  computer  can  read  and  proc- 
ess data  without  additional  human  intervention.  This  means  that  the  data 
must  be  in  coded  rather  than  textual  format.  EDI  standards  provide  a 
widely  accepted  format  to  convey  the  meaning  of  the  exchanged  data. 
They  allow  the  sender  to  encode  data  in  the  same  format  for  many  re- 
ceivers, and  require  the  receiver  to  maintain  only  one  piece  of  software 
to  decode  data  received  from  many  senders.  Standards  for  EDI  have  been 
established  and  maintained  by  several  organizations  for  a  variety  of 
business  functions.  EDI  format  standards  are  intended  to  enhance  EDI 
transactions  across  industry  lines  and  to  foster  a  common  language  for 
cross-industry  EDI  system. 

The  first  attempt  to  develop  standards  occurred  in  the  late  sixties  in 
the  transportation  industry.  In  1%S,  a  group  of  companies  in  the  trans- 
portation industry  joined  together  and  formed  the  Transportation  Data 
Coordinating   Committe   (TDCC).      The   committee   published    its   first 


standards  in  1975  and  has  since  developed  and  published  standards  used 
primarily  in  the  air,  motor,  rail,  and  ocean  carriers.  Other  industries  fol- 
lowed the  TDCC's  lead  and  developed  EDI  standards  for  their  own  in- 
dustries, most  notably  the  grocery  and  the  warehousing  industries.  The 
standards  for  the  grocery  industry  are  termed  Uniform  Communication 
Standards  while  the  standards  for  the  warehouse  industry  are  termed 
Warehouse  Information  Network  standard  (WINS)  [Ref.  3:  p.  64]. 

In  1978,  the  American  National  Standards  Institute  (ANSI)  recog- 
nized the  need  for  national  EDI  standards  that  could  be  used  across  in- 
dustries. ANSI  is  coordinator  and  clearing  house  for  national  and 
international  standards  whose  membership  represents  nearly  all  technical 
disciplines  and  all  areas  of  trade  and  commerce.  ANSI  coordinates 
standards  for  all  facets  of  business.  In  1979,  ANSI  chartered  a  new 
committee,  labeled  the  Accredited  Standards  Committee  (ASC)  XI 2,  to 
develop  uniform  standards  for  cross-industry  electronic  communications. 
According  to  the  X12  committee,  its  function  is  to  develop  standards  to 
faciliate  electronic  interchange  of  data  relating  to  order  placement  and 
processing,  shipping  and  receiving  information,  invoicing,  and  payment. 
The  ANSI  ASC  X12  committee,  using  the  basic  structure  and  syntax  es- 
tablished by  TDCC,  developed  and  continues  to  develop  EDI  standards 


[Ref.  3:  p.  66].  While  TDCC-based  standards  and  the  ANSI  X12  stand- 
ards are  not  identical,  they  use  the  same  basic  architecture  and  employ 
similar  syntax  rules  [Ref.  3:  p.  67]. 

B.     ANSI  X12  STANDARDS 

1.     Organization  of  ANSI  ASC  X12 

The  American  National  Standards  Institute  (ANSI)  has  made  a 
significant  contribution  to  the  development  of  Electronic  Data  Inter- 
change transactions  across  industry  lines,  using  standardized  protocols. 
Since  1918,  this  organization  has  been  responsible  for  approving  engi- 
neering and  industrial  standards.  ANSI  does  not  actually  establish 
standards.  They  are  responsible  for  approving  estandards  that  have  been 
developed  by  committees  of  experts.  ANSI  uses  a  rigorous  consensus- 
based  process  for  the  establishment  of  standards.  As  the  official  voluntary 
standard-setting  organization  for  the  United  States,  ANSI  sanctioned  the 
Accredited  Standards  Committee  X12  (ASC  XI 2)  to  develop  the  neces- 
sary standards.  This  committee  was  made  up  of  representatives  of 
commerical  and  industrial  organizations,  and  vendors  of  services  designed 
to  facilitate  the  use  of  Electronic  Business  Data  Interchange  Standards. 
The  scope  of  X12  is  to  provide  standardization  to  facilitate 
interbusiness/institutional  electronic  interchange  of  transactions 'relating 


to  order  placement  and  processing;  shipment  and  receiving  information; 
invoicing;  payment;  and  application  data.  The  X12  organization  is 
structured  into  committees  and  subcommittees  as  showen  in  Figure  1 
[Ref.  3:  p.  77]. 

The  two  major  committees  are  the  Steering  Committee  and  the 

Procedures  Review  Board  who  are  responsible  for  the  following: 

•  Steering  Committee  performs  administrative  functions  for  X12  and 
provides  coordination  among  subcommittees  and  task  group. 

•  Procedure  Review  Board  (PRB)  reviews  all  project  proposals  sub- 
mitted to  the  committee.  It  manages  draft  standards,  standards 
maintenance,  and  compliance  guidelines.  [Ref.  3:  p.  78] 

In  addition  to  the  two  major  committees,  there  are  nine  standing 
subcommittees.  Six  of  the  subcommittees  represent  functional  area  in- 
terests :  product  data,  materials  management,  purchasing,  finance  trans- 
portation, and  government.  Three  of  the  subcommittees  deal  with  issues 
of  a  broader  nature.  The  Technical  Assessment  Subcommittee  reviews 
draft  proposals  to  determine  if  they  are  within  the  scope  of  X12's  activ- 
ities and  also  ensure  the  consistency  within  X12  standards.  The  Educa- 
tional and  Implementation  Subcommittee  acts  as  the  public  relations  arm 
of  XI 2.  In  addition  to  the  two  major  committees  and  nine  subcommit- 
tees two  other  groups  play  a  part  in  the  X12  organization.  The  Data 
Interchange  Standards  Association  (DISA)  acts  as  the  secretariat  for  the 


X12  membership 


Secretariat^. I. S. A) 


X1 2  chair      - 


Procedures   review  board 


North  american  EDIFACT 


Z 


E 

Sub 

Committee 

Product 

Data 


I 


F 

Sub 

Committee 

materials 

management 


G 

Sub 

Committee 

Purchasing 


r 


Subcommittee 
communication 


Steering      committee 


EDI    seminar 


T 


H 

Sub 

Committee 

Finance 


I 

Sub 

Committee 

Trans 

portation 


K 

Sub 

Comn  ittee 
Goverment 


Subcommittee 
Education  & 
implementation 


1 


Subcommittee 

Technical 

Assessments 


Figure  1.      ANSI  X12  organization 


X12  organization.  DISA  performs  administrative  functions  such  as 
printing,  distribution,  and  storage  of  the  standards.  The  X12  organization 
also  participates  in  development  of  standards  on  an  international  basis 


by  having  X12  members  serve  as  representatives  to  the  North  American 


EDIFACT  (Electronic  Data  Interchange  for  Administration,  Commerce 
and  Transport)  board. 

Any  individual  or  organization,  whether  a  member  of  the  X12 
committee  or  not,  can  request  that  a  new  standard  be  developed,  or  that 
a  change  be  made  to  an  existing  standard.  Such  a  request  is  usually  sub- 
mitted to  the  secretariat,  who  forwards  the  request  to  the  Technical  As- 
sessment Subcommittee,  as  shown  in  Figure  2  [Ref.  3:  p.  80]. 

If  the  request  is  within  the  scope  of  XI 2,  the  Technical  Assessment 
Submittee  forwards  the  request  to  the  pertinent  subcommittee  for  review. 
The  subcommittee  prepares  a  formal  project  proposal  based  upon  the 
work  request,  which  is  submitted  back  to  the  Technical  Assessment  sub- 
committee for  a  consistency  check  with  other  standards.  If  the  proposal 
passes  this  check,  it  is  sent  to  the  Procedure  Review  Board  for  one  more 
vote  on  whether  the  proposal  is  within  the  scope  of  X12  and  is  consistent 
with  other  standards.  If  this  vote  is  positive,  then  the  proposal  is  referred 
back  to  the  original  subcommittee  for  actual  standards  development. 
Final  approval  authority  for  all  business-related  standards,  not  only  EDI 
standards,  rests  with  ANSI.  Whenever  ANSI  receives  a  proposed  standard 
from  any  Accedited  Standards  Committee,  such  as  XI 2,  ANSI  sends  the 
proposed  standard  out  for  public  review  and  comment,  a  process  that  can 
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Figure  2.      ANSI  X12  maintenance/development  flow 


take  two  to  three  years.  Only  after  the  review  process  is  completed  is  the 
standard  approved  and  released  as  an  ANSI  approved  standard.  In  the 
EDI  community,  standards  are  considered  approved  once  they  have  been 
accepted  by  the  X12  committee.  So,  although  most  ANSI  EDI  standards 
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carry  the  offical  title  of  draft  standards,  they  are  the  standards  in  use  and 
accepted  by  the  EDI  community  [Ref.  3:  p.  80]. 
2.     Description  of  ANSI  X12  standards 

The  X12  committee  continued  development  of  business  trans- 
actions which  would  support  the  use  of  computers  in  the  day-to-day 

interchange  of  business  data.    The  ANSI  X12  standards  consists  of: 

•  Transaction  set  standards 

•  Data  element  dictionary 

•  Data  segment  directory 

•  Transmission  control  standards.    [Ref.  2:  p.  63] 

Transaction  set  standards  define  the  format  and  context  of  data 
used  within  specified  business  documents,  such  as  invoices.  (The 
ANSI-approved  transaction  set  standards  are  listed  in  Figure  3.)  How- 
ever, while  the  invoice  transaction  set  (810)  conveys  the  functionality  of 
the  paper  invoice,  it  does  not  contain  as  much  descriptive  information, 
since  it  is  not  intended  for  human  reading. 

The  data  dictionary  contains  codes  for  types  of  information  used 
in  business  documents.  The  data  dictionary  reduces  vast  amounts  of  in- 
formation to  two-digit  codes  (called  data  elements),  and  therefore  elimi- 
nates the  need  for  descriptive  information  in  an  electronic  document. 

n 


ANSI  X12.M986 

Purchase  Order  Transaction  Set  (850) 

ANSI  X12.2-1986 

Invoice  Transaction  Set  (810) 

♦ANSI  X12.3-1986 

Data  Element  Dictionary 

ANSI  X12.4-1983 

Remittance/Payment  Advice  Transaction  Set  (820) 

♦ANSI  X12.6-1986 

Application  Control  Structure 

ANSI  X12.7-1986 

Request  for  Quotation  Transaction  Set  (840) 

ANSI  X  12.8-1986 

Response  to  Request  for  Quotation  Transaction  Set 

(843) 

ANSI  XI  2.9-1986 

Purchase  Order  Acknowledgement  Transaction  Set 

(855) 

ANSI  X12.12-1986 

Receiving  Advice  Transaction  Set  (861) 

ANSI  X12.13-1986 

Price/Sales  Catalog  Transaction  Set  (832) 

ANSI  X12.14-1986 

Planning  Schedule  with  Release  Capability  Transac- 

uon Set (830) 

ANSIX12.15-1986 

Purchase  Order  Change  Request  Transaction  Set 

(860) 

ANSI  XI 2. 16-1986 

Purchase  order  Change  Request  Acknowledgement 

Transaction  Set  (865) 

*  ANSI  XI  2.20-1986 

Functional  Acknowledgement  (997) 

♦ANSIX12.22-1986 

Data  Segment  Directory 

Figure  3.      American  national  standards  for  electronic  business  data 


The  data  segment  dictionary  provides  the  definition  and  formats  for 
data  segments.  These  data  segments  consist  of  a  precise  sequence  of  data 
elements,  separated  by  delimiters. 

The  transmission  control  standards  define  the  formats  for  the  in- 
formation required  to  interchange  data.  Defined  within  the  transmission 
control  standards  are  data  element  delimiters,  transaction  set  separators, 
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and  transmission  envelope  formats.  Figure  4  [Ref.  2:  p.  67]  illustrates  a 
typical  paper  invoice.  Within  the  electronic  invoice,  as  with  each  trans- 
action set,  there  are  three  general  areas  that  relate  directly  to  the  format 

of  the  printed  document  : 

•  The  header  area  contains  preliminary  information  that  pertains  to  the 
entire  document,  such  as  the  date,  company  name,  address,  p.o. 
number,  number,  and  so  on. 

•  The  line  item  area  encompasses  the  actual  business  transaction  and 
includes  such  information  as  quantities,  descriptions  and  prices. 
Again,  in  EDI,  each  line  is  called  a  data  segment,  and  each  item 
within  the  segment  becomes  a  data  element. 

•  The  summary  area  contains  control  information  and  other  data  that 
relate  to  the  total  transaction. 

To  generate  electronic  documents,  the  information  contained  in 
the  invoice  is  replaced  with  the  appropriate  X12  codes,  as  compiled  in  the 
data  dictionary.  Data  elements  are  separated  by  asterisks  (*);  data  seg- 
ments are  separated  by  "N/L"  indicators.  A  line-by-line  comparison  of  the 
X12  invoice  and  the  paper  invoice  of  Figure  5  [Ref.  4:  p.  53]  appears  in 
Figure  6  [Ref.  4:  p.  54]. 

In  Electronic  Data  Interchange,  each  line  is  called  a  segment  and 
each  item  within  the  segment  becomes  an  element. 

The  benefits  derived  from  the  use  of  a  standard  format  for  a  spe- 
cific transaction  set  are  many  fold.  In  one  surveyed  organization,  it  was 
estimated  that  more  than  400  different  purchase  order  formats  were  being 
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Figure  4.      ANSI  X12  interchange  structure 


received  weekly.  The  potential  EDI  user  should  recognize  the  important 
benefits  that  result  from  the  use  of  a  single,  standard  format  purchase 
order  for  all  buying  and  selling  activities.  Even  the  company  which  de- 
sides  not  to  transmit  business  data  electronically  could  benefit  from  the 
use  of  standardized  transactions.  This  simplification  in  transacting  data 
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Purchase  Order    Date  04/2-3/84             Page  1  of 

5KK3-05530 

To:       Selling  Pany        400061                   Buyer  Contact           JJJJESi  ft*., 
123  E.  West  St.                               Joan  Buyes             Packages.  Sh,pp.ng 
Anytown.  USA  99999                                                       Documents  &  Invoices. 

From:  Buying  Party       162                        Ship:    Ship  To  Pany       1100 
444  W  East  Ave                                       Receiving  Dock 
Downtown.  USA  99999                              100  Mam  St. 

Downtown.  USA  99999 

Ship             FOB           Freight  Allowance           Terms                Ship  Date           Due  Date 

Truck           Mill             LessC/LFA                   2/20LCC           05/13/84            05/15/84 

Line 
No. 

Your             Our 
Item  No.  I  Item  No. 

Item  Description 

Unit 
Price 

Quantity 

UOM 

Item 
Due  Date 

1 

20784 

1147560 

23x35  810C  Shasta 
Gl  Bk  Whte 

56.75 

16 

Ctn 

05/15/84 

16 

Ctn 

05/22784 

2 

14096 

1124486 

23x35  880  Shasta 

16 

Ctn 

05/29/84 

59  50 

16 

Ctn 

3 

51193 

1107820 

Suede  Bk  Wh 
23/35  Offset  Opaq 

46.00 

16 

Ctn 

Vellum 

Figure  5.      Original  purchase  order 

is  supported  by  widespread  acceptance  of  ANSI  X12  business  data  inter- 
change standards. 

Figure  7  further  illustrates  the  ANSI  transaction  development 
process  leading  to  standards  publication.  A  number  of  project  teams  and 
subcommittees  are  involved.  Firms  without  participation  in  the  standard 
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nefaleU  Puici«aso  Oder  Seclion 

ST '850 •  0400  N/L 

DEG"00"SA-5KK3  05530' "  -8-10423  N/L 

Purchase  Order 

Date  04/23/04         5KK3  05530 

This  Number  Must 
Appear  on  all  Boxes. 
Packages,  Shipping 
Documents  &  Invoices 

NrSE-92'400061  N/L 

NfBV9r  162N/L 
PEP*  SO 'Joan  Buyes  N/L 

NrST-,91' 1100  N/L 

ITD-0l-03-2'"20N/L 
SHH-SD*0I0-8'10513  N/L 
SHH- DO '002 '8405 15  N/L 
FOB '  PP '  M 1 - Less  C/L  FA  N/L 
T02,0-E  N/L 

To:        Selling  Parly        400061 
123  E  Wesi  SI 
Anytown.  USA  99999 

From    Buying  Parly        162 
444  W  Easl  Ave 
Downtown,  USA  99999 

Buy§r  Contact 
Joan  Buyes 

Ship     Ship  To  Parly       1100 
Receiving  Dock 
100  Main  Si. 
Downtown,  USA  99999 

POlT48,CT-56  75-QT"IN-1l47560-VN '20784  N/L 
SCH-16XT 002-8405 IS  N/L 

SCH-16-CT 002*840522  N/L 

SCW  16'CT 002-840529  N/L 

POT 2*  16'CT -59  5'OT- IN- 1 124486' VN- 14096  N/L 
POT3 •  16XT -46-OT  •  IN -1 107820*  VN- 51  193  N/L 

Terms 
2/20LCC 

Ship  Dale           Due  Date 
05/13/84            05/15/84 

FOB           Freight  Allowance 

Mid           Less  C/L  FA 

C1T3-80N/L 
SE  Mr  8400  N/L 

Ship 
Truck 

Line 
No 

Your 
Item  No 

Our 
Item  No 

Item  Description 

Unit 
Price 

Quantity 

UOM 

Hem 
Due  Date 

1 

2 
3 

20784 

14096 
51193 

1 147560 

1 124406 

1107820 

23x35  8100  Shasta 
Gl  Bk  Whle 

23x35  880  Shasta 
Suede  Bk  Wh 
23/35  Ollsel  Opaq 
Vellum 

56  75 

16 

cm 

05/15/84 

59  50 
46  00 

16 

Cln 
Cln 
Cln 

05/22/84 
05/29/84 

16 
16 

ieT_ 

Cln 



Figure  6.      Translation  of  purchase  order 


setting  process  should  familiarize  themselves  with  the  process  and  con- 
sider some  form  of  participation  [Ref.  4:  p.  52]. 
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Figure  7.      Transaction  development  process 


C.     EDIFACT 


Until  relatively  recently,  most  UK  and  European  EDI  users  have 
based  their  standards  on  the  United  Nations  Trade  Data  Interchange 
(UNTDI)  syntax  (United  Nations  Economic  Commission  for  Europe: 
Guideline  for  Trade  Data  Interchange).  This  system  is  highly  flexible  and 
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provides  guidelines  on  syntax  (character  sets  and  transmission  formatting 
rules)  and  on  segment  and  message  construction.  There  is  also  an  asso- 
ciated directory  of  data  elements,  data  elements  being  the  basic  compo- 
nents of  an  EDI  message  [Ref.  3:  p.  60]. 

It  should  be  noted  that  recent  initiatives  have  been  taking  place  to 
bridge  the  differences  which  exist  between  the  UNTDI  syntax  and  the 
American  National  Standards  Institute's  equivalent  system  known  as 
ANSI  XI 2.  The  objective  is  to  allow  the  building  of  EDI  standards  which 
will  be  valid  for  trade  across  international  boundaries.  The  project  began 
life  as  a  joint  effort  between  European  and  American  EDI  experts,  and 
was  christened  Joint  Electronic  Data  Interchange  (JEDI).  Following  the 
agreements  reached  by  the  JEDI  representees  on  principles  and  syntax, 
the  project  has  received  widespread  support  from  the  many  countries  and 
user  communities  and,  importantly,  from  the  ECE  (Economic  Commis- 
sion for  Europe).  It  is  known  as  Electronic  Data  Interchange  for  Ad- 
ministration, Commerce  and  Transport  (EDIFACT). 

The  new  EDIFACT  EDI  syntax  has  alway  been  accepted  as  a  full 
international  standard:  ISO  9735.  The  EDIFACT  syntax  is  not  greatly 
dissimilar  from  UNTDI,  but  there  are  some  important  differences  which 
also  have  an  impact  on  the  method  of  standard  message  design.    Inter- 
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national  standard  messages  (UNSMs)  are  now  being  developed  as  part 
of  the  EDIFACT  project,  which  is  coordinated  by  the  EDIFACT  board 
and  steering  committee.  Advanced  drafts  of  the  invoice  and  order  files 
are  already  available.  Other  files  are  being  developed  as  quickly  as  possi- 
ble in  order  of  perceived  priority.  UNSMs  are  being  based  on  the  United 
Nations  data  element  directory  with  new  elements  being  created  as  nec- 
essary. They  also  use  the  concept  of  qualifiers,  well  established  in  ANSI 
X12  standards.  Qualifiers  are  codes  used  to  confer  a  specific  function 
or  identify  on  a  generic  data  element  or  segment.  Further  details  on  the 
availability  of  UNSMs  and  on  the  EDIFACT  project  in  general  are  ob- 
tainable from  the  UK  Simplification  of  International  Trade  Procedures 
Board  (SITPRO).  The  EDIFACT  standards  or  syntax  will  not  imme- 
diately or  indeed  ever  supercede  or  outmode  standards  based  on  UNTDI, 
which  have  a  large,  established  and  successful  user  base.  Nevertheless, 
there  is  growing  support  in  principle  for  the  evolution  toward  EDIFACT 
standards  as  the  solution  for  EDI  across  national  boundaries  [Ref.  5:  p. 
31]. 
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D.     CALS 

1.     Background 

We  have  witnessed  a  rapid  growth  in  technology  and  in  product 
complexity,  and  with  that  growth  has  come  an  increasing  volume  of 
product  information  in  recent  years.  As  the  systems  we  develop  become 
more  complex,  the  teams  needed  to  design  and  develop  these  systems 
become  more  specialized.  Sophisticated  documentation  and  information 
exchange  are  necessary  to  hold  an  organized  development  effort  together. 
Governments,  contractors,  subcontractors,  and  developments  within 
companies  all  need  to  share  information  rapidly  and  effectively.  When- 
ever information  is  unusable  or  needs  to  be  converted  to  another  form 
or  retyped  into  a  different  computer  system,  there  is  wasted  effort  and 
delay  in  the  development  cycle,  which  costs  time  and  money. 

The  United  States  Department  of  Defense  (DoD)  has  recognized 
the  need  to  increase  the  efficiency  and  productivity  of  development  efforts 
and  the  quality  of  final  products.  The  DoD  plans  to  achieve  this  by 
modernizing  the  information  systems  that  support  the  life  cycle  of  defense 
weapon  systems.  By  specifying  the  form  and  structure  of  weapon-systems 
data  bases,  the  DoD  is  promoting  more  effective,  accurate,  and  efficient 
information  exchange  among  DoD  agencies,  military  services,  and  indus- 
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try  partners.  The  effort  was  launched  in  1985  as  a  DoD  task  force  project 
through  a  directive  from  the  Deputy  Secretary  of  Defense,  William  H. 
Taft.  Known  as  the  Computer-aided  Acquisition  and  Logistics  Support 
(CALS)  initiative,  it  has  become  a  committed  direction  for  all  U.S. 
weapon  systems.  The  product  of  this  initiative  is  a  set  of  military  stand- 
ards and  specifications  that  define  formats,  structures,  and  protocols  for 
the  information  that  is  exchanged  [Ref.  6:  p.  4-1]. 

While  the  DoD  and  its  industry  partners  are  designing  and  imple- 
menting CALS  systems,  other  government  agencies,  manufactures  of 
high-tech  products,  and  governments  worldwide,  particularly  Canada  and 
European  countries,  are  becoming  aware  of  the  benefits  of  such  a  system. 
Some  of  these  organizations  have  begun  to  adopt  the  CALS  standards 
and  specifications,  in  whole  or  in  part,  as  the  basis  of  their  information 
systems.  Thus,  what  started  as  a  DoD  initiative  is  becoming  a  global 
model  for  information  systems  supporting  complex  technical  products  of 
the  future. 

The  initial  phase  of  CALS  standardizes  the  exchange  of  textual 
and  graphic  documentation  for  both  printed  copy  and  digitally  commu- 
nicated information.  The  long-term  goal  of  the  CALS  initiative  is  a 
totally  integrated   weapon-systems  data  base   in  which  all   information 

21 


about  a  weapon  system  resides.  Rather  than  exchanging  information  on 
various  media,  such  as  paper  or  magnetic  tape,  authorized  users  will  ac- 
cess a  data  base  to  get  the  information  they  require.  Thus,  users  who  need 
accurate,  up-to-date  information  can  get  it  quickly  and  efficiently.  The 
immediate  and  long-term  benefits  of  a  CALS  system  are  substantial,  in- 
cluding: 

•  Reduction  in  the  product  development  cycle 

•  Reduction  in  development  and  service  costs 

•  Increase  in  the  accuracy  of  product  information 

•  Improvement  in  the  integrity  and  readiness  of  the  weapon  system. 
[Ref.  7:  p.  16] 

2.     What  is  CALS? 

Computer-aided  Acquistition  and  Logistics  (CALS)  is  a  strategy 
that  the  DoD  and  its  industry  partners  are  using  to  enable  and  accelerate 
the  integration  of  the  digital  technical  information  that  is  associated  with 
the  acquisition,  design,  manufacture,  and  support  of  a  weapon  system. 
CALS  provides  for  a  transition  from  current,  paper-intensive  processes 
to  the  efficient  use  of  digital  information  technology.  The  first  phase  of 
the  CALS  initiative  focuses  on  technical  publications  and  the  information 
used  to  create  them.  Traditionally,  the  process  of  acquiring  an 
information-processing  system  has  been  difficult  and  expensive.  Each 
weapon  system  has  its  own  requirements;  therefore,  building  the  appro- 
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priate  information-processing  system  means  continually  reevaluating,  up- 
grading, and  reconfiguring  the  existing  equipment  and  software,  and 
possibly  migrating  to  an  entirely  new  system.  The  CALS  approach  to  this 
challenge  is  to  put  all  the  information  about  the  product,  from  design 
specification  to  engineering  drawings  to  project  management  data  to 
technical  manuals,  in  an  integrated  data  base.  If  all  the  information  is  in 
one  data  base  in  standard  formats,  the  need  to  covert  or  reformat  the 
information  is  greatly  reduced.  Those  who  need  to  use  the  information 
or  contribute  to  the  data  base  simply  access  the  data  base  through  defined 
query  or  retrieval  interfaces.  A  central  data  base  helps  users  more  easily 
access  information,  in  essence  bringing  the  information  to  the  users.  It's 
their  responsibility  to  use  a  system  that  can  communicate  with  the  data 
base  and  accept  and  deliver  information  in  the  proper  format. 

An  integrated  data  base  is  the  solution  for  which  the  CALS  com- 
munity is  striving.  However,  there  are  a  number  of  hurdles  to  overcome 
first,  one  of  which  is  standardization  of  information  and  data  formats. 
Therefore,  the  immediate  goal  is  to  improve  the  process  of  exchanging 
information  among  different  computing  systems.  In  the  initial  phase  of 
CALS  the  DoD,  working  with  industry  steering  groups,  has  defined  se- 
veral standards  and  specifications.    Drawing  from  existing  international 
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standards,  the  CALS  committees  have  defined  the  acceptable  formats  for 
textual,  graphic,  image,  and  engineering  information.  Figure  8  [Ref.  7: 
p.  14]  provides  a  brief  summary  of  the  primary  CALS  standards  and 
specification  that  the  DoD  has  defined. 

By  standardizing  the  format  of  information,  the  DoD  can  be  sure 
that,  regardless  of  what  computer  system  the  information  comes  from, 
other  computer  systems  can  process  it.  It's  up  to  everyone  involved  to  use 
a  system  that  can  accept,  process,  structure,  and  deliver  the  information 
in  a  format  that  conforms  to  the  CALS  standards  and  specifications. 
3.     Relationship  between  EDI  and  CALS 

The  relationship  between  EDI  and  CALS  can  be  summarized  by 

the  following  positions  taken  by  DoD  and  NIST. 

•  December  1988,  MIL-HDBK-59;  CALS  will  use  EDI  transaction  sets 
for  exchanging  technical  information. 

•  March  1989,  DoD  recommendation  are  link  CALS  data  and  EDI 
data  into  one  protocol.  As  proposed  by  automotive  industry  action 
group  (AIAG)  and  DOD  memo  stating  that  a  "common  technical 
approach"  be  taken  to  ensure  "complementary  implementation"  of 
CALS  and  EDI. 

•  Sept  1989,  Dept  of  commerce  (NIST)  published  "Transmission  of 
CALS  1840A  technical  data  through  the  use  of  X12  EDI  transaction 

set  841". 


• 


EDI  transaction  set  841,  Specifications/Technical  Information,  has 
been  specified  in  ANSI  XI 2.51  by  its  Product  Data  Subcommittee. 
It  provides  for  the  exchange  of  complete  or  partial  specifications  or 
technical  information  related  to  products  and  services  [Ref.  7:  p.  22]. 
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Standard  or  specification 

Description 

Military  Standard  MIL-STD-1840A:   Automated  Inter- 
change ol  Technical  Information 

An  "umbrella"  standard  that  describes  all  of  the 
requirements  lor  delivering  CALS  documents. 
MIL-STD-1840A  refers  to  the  military  specifications 
listed  below.   It  also  describes  how  information  is  to 
be  loaded  onto  magnetic  tape  for  delivery. 

Military  Specification  MIL-M-387848:   Manuals,  Tech- 
nical:  General  Style  and  Format  Requirements 

Describes  the  general  requirements  for  military  doc- 
umentation, Irom  content  and  style  to  page-layout 
specifications. 

Military  Specification  MIL-D-28000:  Digital  Represen-      I    Describes  the  format  lor  graphics  files  containing 
tation  for  Communication  of  Product  Data:  IGES  Appli-     i    engineering  information. 
cation  Subsets 

Military  Specification  MIL-M-28001  and  MIL-M-28001  A: 
Markup  Requirements  and  General  Style  Specification 
lor  Electronic  Printed  Output  and  Exchange  of  Text 

Describes  the  format  for  text  files    Basically, 
MIL-M-28001  defines  Standard  Generalized  Markup 
Language  (SGML)  document  type  definitions  (DTD)  for 
CALS  documents.   A  later  section  of  this  book 
describes  how  CALS  uses  SGML. 

MIL-R-28002:  Raster  Graphics  Representation  in 
Binary  Format,  Requirements  tor 

Describes  the  format  for  raster  (dot-oriented)  graphics 
files. 

MIL-D-28003:  Digital  Representation  tor  Communi- 
cation of  Illustration  Data:  CGM  Application  Profile 

Describes  the  format  for  vector  (line-oriented) 
graphics  files. 

Figure  8.      CALS  standards  and  specification 
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III.     ANALYSIS  OF  TRANSACTION  AND  DATA  MAPPING 

A.     TRANSACTION  AND  DATA  FLOW 

The  introduction  of  Electronic  Data  Interchange  can  impact  the 
documents  traditionally  used  to  transmit  necessary  information.  EDI  can 
eliminate  nearly  all  external  paper.  This  section  has  two  major  objectives. 
The  first  is  to  document  the  flow  of  paper  in  a  traditional  manual  pur- 
chasing and  material  management  system.  The  second  objective  of  this 
section  is  to  explain  how  the  paper  flow  may  change  as  a  firm  evolves 
from  a  manual  to  a  computerized  purchasing  system  with  EDI. 

In  a  manual  purchasing  system  for  a  typical  purchasing  department, 
a  paper  flow  is  established  to  support  its  routine,  day-to-day  activity,  and 
this  flow  provides  information  to  a  multitude  of  different  individuals  lo- 
cated in  several  functional  departments.  This  paper  flow  has  developed 

over  time  into  a  series  of  procedures  that  meet  four  basis  concepts: 

•  The  flow  of  paper  permits  the  efficient  use  of  purchasing  resources 
in  conducting  the  routine  activities  of  the  department.  Most  paper- 
work is  done  by  clerks  instead  of  managers. 

•  The  flow  of  paper  provides  needed  information  to  the  various  de- 
partment that  are  affected  by  the  placement  of  an  order,  e.g.,  manu- 
facturing control,  inventory  control,  receiveing,  accounting,  etc. 

•  The  standard  flow  of  documentation  is  clearly  defined.  The  reason 
for  this  standardization  of  procedures  is  so  that  the  multitude  of 
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clerks  supporting  the  system  can  process  the  documentation  with 
minimum  effort  and  uncertainty. 

•  The  flow  of  documentation  permits  managerial  discretion.  When 
conditions  arise  that  are  not  routine  or  normal,  responsible  managers 
are  informed  about  the  condition.  These  managers  can  take  correc- 
tive action  before  any  problem  arises.    [Ref.  4:  p. 37] 

The  flow  of  paper  in  a  manual  purchasing  system  such  as  the  one  il- 
lustrated in  Figure  9  [Ref.  4:  p. 39]  accomplishes  these  conditions. 
The  normal  paper  flow  shown  in  Figure  9  is  quite  complex  because  of  the 
continuous  flow  and  enormous  quantitites  of  paper  generated  and 
stored.  Unless  these  documents  are  organized  in  a  systematic  manner, 
much  of  the  information  contained  in  these  documents  would  be  useless 
to  purchasing  and  other  departments  within  the  firm.  Figure  10  [Ref.  4: 
p.40]  shows  a  simplified  inter-firm  transfer  of  documents  on  a  manual 
basis. 

In  a  computerized  purchasing  system,  EDI  has  been  defined  as  the 
exchange  of  business  information  from  one  firm  to  another  in  machine 
readable  form.  EDI  was  developed  to  eliminate  the  external  documenta- 
tion between  a  supplier  and  buyer,  not  the  internal  paper.  A  computerized 
purchasing  information  system  with  or  without  EDI  is  needed  to  elimi- 
nate much  of  the  internal  documentation.  Many  firms  have  computerized 
purchasing  information  systems  without  EDI  that  are  quite  sophisticated. 
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Figure  9.      Manual  system 


Such  information  systems  have  various  modules  for  on-line  purchase  or- 
der, purchase  order  change  notice,  receiving  inspection,  and  inquiry. 
They  also  have  interfaces  with  accounts  payable  and  requirements  plan- 
ning. By  and  large,  these  sophisticated  purchasing  information  systems 
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have  eliminated  much  of  the  internal  paper  generation  through  intelligent 
design  and  without  the  use  of  EDI  [Ref.  4:  p.  40]. 

EDI  involves  external  communication  with  suppliers.  Figure  1 1  [Ref. 
4:  p.  42]  illustrates  the  communications  between  buyer  and  seller  for  a 
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fairly  sophisticated  EDI  system.  The  elimination  of  paper  requires  a  well 
planned  sequence  of  events.  Even  though  the  EDI  system  is  electronically 
sophisticated,  some  purchase  orders,  acknowledgement,  requests  for 
quote,  etc..  for  certain  purchase  items  may  still  be  sent  by  mail.   It  is  also 
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desirable  to  maintain  a  direct  communication  channel  between  the  buying 
firm  and  one  or  more  suppliers,  even  though  a  third-party  network  is  in 
operation.  This  direct  communication  can  be  by  means  of  computer, 
telephone,  and/or  mail.1  In  sum,  an  integrated  purchasing/EDI  system, 
where  both  digital  and  manual  methods  of  communication  are  available, 
is  a  very  desirable  type  of  system  configuration.  An  integrated 
purchasing/EDI  system  such  as  the  one  pictured  in  Figure  1 1  can  elimi- 
nate most  of  the  external  physical  documentation  and  still  maintain  the 
flexibility  critical  to  any  purchasing  system. 

Several  issues  arise  for  a  firm  operating  in  an  EDI  environment.  One 
key  issue  concerns  the  storage  of  electronically  transmitted  purchase 
documents.  A  decision  concerning  an  appropriate  storage  mechanism, 
e.g.,  magnetic  tape,  hard  disk,  floppy  disk,  microfiche,  etc.,  must  be  made 
by  all  firms  involved  in  the  EDI  system  [Ref.  3:  p.  38]. 

Another  issue  concerns  the  operation  of  a  parallel  purchasing  system 
during  the  initial  phase  of  EDI  implementation.  Both  hard-copy  of  the 
purchase  order  and  the  EDI  transaction  would  be  sent  to  suppliers.  Par- 
allel systems  are  a  necessity,  but  frequently  short  lived.  For  one  firm,  the 


1  Multiple  third-party  networks  including  a  gateway  may  be  used  to  support  EDI.  From  in- 
formation gathered  in  a  survey,  it  seems  probable  that  the  use  of  third-party  networks  will  increase 
significantly  in  the  future. 
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parallel  system  lasted  only  3-6  weeks  and  was  discontinued  as  soon  as 
each  each  supplier  gained  confidence  in  the  EDI  system  [Ref.  3:  p.  42]. 

A  third  issue  raised  by  the  implementation  of  an  EDI  system  concerns 
job  content.  The  job  of  the  typical  purchasing  professional  in  the  EDI 
environment  can  change  significantly.  Purchasing  personnel  will  spend  a 
much  smaller  percentage  of  their  time  firefighting  and  a  larger  percentage 
of  their  time  planning  purchases.  The  change  in  work  flow  for  buyers 
should  be  carefally  managed.  Buyers  should  continue  to  review  orders. 
After  the  paper  begins  to  disappear,  they  should  print  logs  of  purchase 
orders  and  change  notices  placed  during  any  day.  They  also  have  to  keep 
a  purchase  order  number  as  a  control  number  for  reference  purposes  with 
vendors.  It  is  a  good  policy  to  eliminate  only  one  physical  document  type 
at  a  time  and  initially  keep  the  set  of  vendors  small  [Ref.  3:  p.  43]. 

The  implementation  of  EDI  can  create  a  more  effective  receiving 
function  through  the  better  scheduling  of  receipts.  As  the  paper  disap- 
pears, the  receiving  function  will  be  forced  into  a  closer  integration  with 
the  ordering  function.  The  information  concerning  order  status  and 
shipping  which  at  one  time  was  available  primarily  to  purchasing  can  now 
be  used  by  the  receiving  function  for  a  more  efficient  operation.  With 
the  advent  of  more  frequent  orders  and  a  shorter  purchasing  cycle  time, 
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efficient  receiving  operation  is  important  to  the  proper  functioning  of  the 
entire  procurement  and  manufacturing  system  [Ref.  3:  p.  45]. 

B.     DATA  MAPPING 

Data  mapping  extends  the  EDI  process  by  using  the  values  received 
as  though  they  had  been  entered  into  the  user's  information  system  locally 
[Ref.  8:  p.  2].  A  purchase  order  received  electronically  is  automatically 
entered  into  the  system  as  though  it  had  been  given  verbally  to  an  order 
clerk  and  hand-entered.  A  shipping  notice  is  received  providing  location 
information  on  an  inbound  shipment.  The  values  are  automatically  stored 
in  the  interactive  Database  which  allows  users  to  access  the  information 
at  any  time.  On  the  transmitting  side,  an  invoice  is  developed  from  the 
accounts  receivable  software  and  transmitted  to  the  recipient  without 
human  intervention  at  any  step  of  the  process.  The  computer-to-computer 
portion  of  the  process  (Figure  12)  [Ref.  8:  p.  2]  is  what  we  often  mean 
when  we  say  we  are  doing  EDI.  The  answer  is  where  the  efficiencies  lie. 
Transmitting  a  purchase  order  electronically  will  assuredly  save  time  and 
promote  greater  accuracy,  but  only  to  the  point  where  the  purchase  order 
appears  as  output  of  the  receiving  company's  corporate  information  sys- 
tem. The  computer  system  then  actually  processes  the  purchase  order, 
fully  realizing  the  efficiencies.    Data  mapping  is  the  process  that  will  ac- 
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Figure  12.      Flow  diagram  of  computer-to-computer  EJM 


complish  this  extra  step.  By  taking  the  values  produced  by  the  translation 
software  and  automatically  integrating  these  values  into  procedure  calls, 
database  assignments,  or  some  combination  of  these,  the  most  inefficient 
part  of  the  system  can  be  eliminated.     We  develop  a  conceptual  de- 
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scription  of  data  mapping  under  the  following  five  scenarios  [Ref.  8:  p. 

4]. 

1.    The  paper  system 

A  paper  system  (Figure  13)  [Ref.  8:  p.  8]  does  not  carry  the  data 
beyond  the  translation  process.  On  the  receiving  side,  EDI  transmissions 
are  translated  and  pointed  out  for  further  action.  The  further  action  may 
be  the  use  of  these  values  to  enter  data  into  an  automated  system  that  is 
not  yet  integrated  with  EDI  software.  It  may  be  the  begining  of  a  totally 
manual  process.  On  the  transmitting  side,  data  is  entered  into  the  EDI 
translation  software  via  a  keyboard.  Most  software  packages  provide  the 
user  with  a  great  deal  of  assistance  in  this  process  via  user-friendly  input 
screens,  template  generation,  and  code  selection  capabilities.  Paper  EDI 
systems  are  used  most  often  by  small  companies  who  are  not  prepared  to 
fully  integrate  EDI.  In  many  cases  they  have  been  persuaded  by  a  major 
trading  partner  to  begin  doing  business  via  EDI.  They  may  not  be  able 
to  cost  justify  the  development  of  a  fully  integrated  EDI  system.  Paper 
systems  are  sometimes  used  by  larger  companies  as  part  of  a  pilot  effort 
or  as  a  means  for  getting  into  EDI  quickly  with  the  intent  of  integrating 
later.  Since  a  paper  system  is  a  complete  system,  it  is  a  logical  step  in  the 
build-a-little-test-a-little  process. 
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2.     Integrating  with  the  existing  database 


This  scenario  consists  of  the  most  basic  integration  mode,  that  of 
simply  interfacing  the  EDI  translation  software  with  an  existing  database. 
The  implication  of  this  type  of  activity  is  that  we  will  be  dealing  strictly 
with  static  data  values.   The  translation  software  uses  an  intermediate  flat 
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Figure   14.      Integrating  EDI  ^ith  existing  corporate  database 


file  to  pre-stage  raw  data  for  translation  into  EDI  transaction  sets  and 
as  output  when  interpreting  EDI  transaction  sets.  The  integration  in- 
volved is  the  process  of  programatically  mapping  values  between  the  flat 
file  and  the  appropriate  locations  in  the  corporate  data  base  (Figure  14) 
[Ref.  8:  p.  10].    This  involves  an  analysis  of  the  corporate  use  of  each  el- 
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ement  in  each  transaction  set  to  determine  what  values  will  be  transported 
to  what  database  locations.  This  programming  process  is  the  origin  of 
the  term  data  mapping  which  is  frequently  applied  to  all  of  the  aspects 
of  application  integration  described  in  this  section.  We  shall  use  the  term 
database  mapping  to  describe  the  process  of  mapping  only  static  data,  that 
which  will  not  be  used  immediately  but  will  be  stored  for  future  use.  The 
more  generic  data  mapping  will  be  used  to  include  application  integration, 
the  immediate  employment  of  data  values  as  part  of  a  process  or  proce- 
dure call  where  the  data  values  are  used  as  parameters. 
3.     Integrating  with  existing  applications/processes 

This  scenario  is  similar  to  that  of  data  mapping  except  that  instead 
of  mapping  raw  data  values  from  an  intermediate  file  to  a  database,  data 
are  extracted  and  mapped  into  an  existing  procedure  call  which  will  than 
be  applied  in  its  normal  manner  to  the  corporate  system  (Figure  15)  [Ref. 
8:  p.  1 1].  An  example  of  this  would  be  incorporating  EDI  into  an  existing 
system  that  allows  the  execution  of  computerized  purchase  orders.  The 
integration  of  EDI  would  permit  automatic  execution  of  purchase  orders 
received  via  EDI  transaction  sets.  Note  that,  in  mapping  to  a  database, 
almost  any  type  of  transaction  set  can  be  received  and  mapped.  The  dif- 
ference in  the  scenario  being  described  is  that  only  those  transaction  sets 
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Figure   15.      Integrating  EDI  with  existing  corporate  processes 


can  be  integrated  for  which  an  automated  corporate  process  (e.g.,  placing 
or  receiving  an  order,  sending  or  receiving  an  invoice)  already  exists. 
4.     Developing  new  applications/processes  based  on  EDI 

In  this  scenario,  the  EDI  user  is  interfaced  with  developing  systems 
or  subsystems   for   EDI   transaction   sets  which   do   not  correspond   to 
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Figure   16.      Developing  new  processes  based  on  EDI 


processes  currently  being  used  in  the  corporate  system.  This  type  of  ap- 
proach presupposes  either  a  new  type  of  business  being  created  by  the 
introduction  of  EDI  or  the  recognition  of  the  need  for  new  internal 
processes  due  to  the  advent  of  EDI.  In  either  case,  instead  of  applying 
the  data  to  existing  processes  as  described  in  the  preceding  subsection, 
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new  corporate  processes  will  be  developed  which  include  integrated  EDI 
as  part  of  the  application.  These  would,  in  turn,  be  integrated  into  the 
overall  corporate  information  system  (Figure  16)  [Ref.  8:    p.  13]. 
5.     Fully  integrated  application/EDI  system  development 

The  final  scenario  which  will  be  discussed  in  this  section  is  that 
of  including  EDI  integration  in  the  design  of  a  new  corporate  business 
data  processing  system  (Figure  17)  [Ref.  8:  p.  15].  Many  new  design 
considerations,  in  addition  to  those  normally  experienced  in  a  system 
development  process,  will  be  encountered.  Among  these  are  the  selection 
of  translation  software.  Selecting  or  developing  software  that  can  be 
coupled  directly  with  applications  modules  could  eliminate  or  reduce  the 
need  for  interface  files.  Proceeding  with  the  development  in  this  manner 
could  produce  a  very  efficient,  tight  coupling  between  the  modules  of  the 
system  and  the  translation  software.  These  and  other  complex  decisions 
are  involved  in  the  pursuit  of  this  type  of  development. 
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IV.      HARDWARE  AND  SOFTWARE  REQUIREMENTS 

A.      HARDWARE  REQUIREMENTS 

There  is  actually  no  such  thing  as  unique  EDI  hardware.  EDI  software 
is  available  for  mainframes,  minicomputers,  and  microcomputers.  All  it 
takes  to  do  EDI  is  a  computer  of  some  type,  a  communications  modem, 
and  software.  The  most  common  hardware  and  software  combinations 
used  to  perform  EDI  are  shown  in  Figure  18  [Ref.  9:  p.  90].  As  shown 
in  the  Figure,  three  basic  options  exist:  mainframe  only,  microcomputer 
only,    and  microcomputer  as  a  front-end  processor  to  a  mainframe. 

The  minimum  microcomputer  configuration  to  implement  an  EDI 
system  consists  of:  [Ref.  4:  p.  65] 

Computer 

•  Processor  -  16-bit  minimum 

•  Memory- 256kb,  expandable 

•  Real-time  clock 

Screen  Display 

•  24  line  X  80  character 

Disk  Storage 

•  2  dual-sided  floppy-360k 

•  Optional  :  Hard  Disk  10  MB 
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Figure   18.       Software/hardware  options. 

Communications 

•  Hardware  -  RS232  serial  interface  port 

•  Modem  -  1200  to  9600  Baud,  Bell  201  C  and  208  B  compatible  for 
2780  3780  emulation,  bisynchronous 

•  Communication  lines  -  Bell  208  B  or  equivalent 

•  Software    -    capable    of    communication    with     partner's    PC    or 
mainframe 

Operating  System 
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•  MS-DOS,  Unix,  or  UNIX  compatible 

Programming  Language 

•  Varies  with  choice  of  third  parties  and  industry 

•  Recommend  ANSI  X12 

Printer 

•  Dot  matrix,  160  character/sec,  SO  column  or  136  column 

•  parallel  or  serial  interface 

If  we  include  the  third-party  support  as  an  option,  there  are  four  different 
system  approaches  regarding  hardware  platform  for  EDI,  as  illustrated  in 

Figure  19: 

•  PC-based  configuration 

•  mainframe  based  configuration 

•  PC-to-mainframe  configuration 

•  third-party  support. 

The  advantages  and  disadvantages  and  the  costs  of  these  four  approaches 
are  summarized  in  Figure  20. 

B.     SOFTWARE  REQUIREMENTS 

EDI  software  consists  of  computer  instructions  that  translate  infor- 
mation from  unstructured,  company-specific  format  to  the  structured 
EDI  format  and  then  communicate  the  EDI  message.  EDI  software  also 
performs  this  activity  in  reverse  (receives  the  message  and  translates  from 
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standard  format  to  company-specific  format).  i_OI  software  can  be  de- 
veloped in-house  or  it  can  be  purchased  from  a  number  of  commercial 
software  vendors.  EDI  can  be  performed  on  various  types  of  computers 
and  software  is  currently  available  for  EDI  applications  using  mainframe 
computers,  minicomputers,  or  microcomputers  (PCs).    The  major  func- 
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Sample    Costs    for    Buyer 

Advantages 

Disadvantages 

Hardware:$4000.00 

Lowest   system  cost 

Limited   data   volume 

Software   :   $1000.00 

Allows   for  multiple 

Harder  to   secure   system 

to    $10000.00 

stations 

Require    each    partner 
Same   baud   rate 
Same   protocol 

Hardware   :    $10000. 

Can  handle  high 

Costs  of  hardware 

to    $100000. 

volume  of  data 

Same   baud   rate 

Software   :  $1000. 

Larger  Data  Base 

Require    each    partner 

to   $20000. 

Better    security 

Hardware    :   $4000 

Support  Remote  job 

PC  user  limited 

Software   :   $1000 

Handle   higher  volume 

Require  each   partner 

to    $10000 

One-to-many  EDI 

Same   baud  rate 

system 

Additional    software 

Hardware:    $4000. 

Better    security 

Added   costs 

to    $100000. 

Mailbox    services 

Addsadditional   link   to 

Software   :   Variable 

Multiple    destination 
Access   to  satalies 
Allow  long  distance 

the  EDI  transaction  cycle 

Figure  20.      Advantage  and  disadvantage 


tion  that  EDI  software  performs  is  formatting  or  translation.  Formatting 
software  generally  uses  a  table  structure  to  perform  the  translation.  The 
software  includes  tables  consisting  of  the  standard  data  dictionary-  and 
syntax  rules  for  the  data  segments  and  elements  of  a  given  EDI  trans- 
action set.  The  actual  transmission  of  the  EDI  message  is  controlled  by 
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communications  software.  This  software  manages  and  maintains  phone 
numbers  of  trading  partners,  performs  automatic  dialing,  and  also 
produces  an  activity  log. 

Figure  21  [Ref.  3:  p.  92]  shows  the  normal  sequence  of  activities  per- 
formed by  EDI  software  for  both  incoming  and  outgoing  EDI. 

There  are  a  number  of  software  categories  associated  with  an  EDI 

system.  These  include: 

•  Database  management  software:  Designed  to  systematically  organize 
data  into  files  for  easy  access,  retrieval,  and  update. 

•  Format/conversion  or  translation  software:  User  information  input 
into  transaction  format  (ANSI  XI 2)  and  then  converted  to  the  elec- 
tronic transmission  protocol.  Also  capable  of  converting  transmitted 
data  from  the  communications  protocol  to  the  transaction  format 
(ANSI  X12). 

•  Communication  software:  Controls  the  data  being  transmitted  via 
phone  lines  to  and  from  EDI  partner.    [Ref.  3:  p.  66] 

EDI  software  may  be  one  of  the  following: 

•  Internally  developed  software 

•  Commercially  available  software 

•    Database  management  software:  ranges  from  $199.00  to  $3,000.00. 

■  Communications    packaged    software:    ranges    from    $99.00    to 
$1,000.00. 

■  EDI  format/protocol  software 

Most  of  the  following  features  are  available  in  commercially  devel- 
oped software,  and  should  be  included  in  any  in-house  developed  soft- 
ware. 
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Figure  21.      Function  of  EDI  software 

•  Table-driven  structure 

•  Editing  capability 

•  Customize  ease 

•  Audit  options 


Three  major  factors  should  be  considered  in  determining  whether  your 
organization  should  buy  a  commercially  available  software  pack- ^e  or  it 

should    develop  the  software  in-house.  They  are: 

•  In-house  resources 

•  Maintenance  required 
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•  Company  policy 

If  your  organization  decides  to  buy  rather  than  develop  software  in- 
house,  you  will  be  faced  with  selecting  among  a  number  of  software  ven- 
dors. In  evaluating  commerically  available  software  packages  and  vendors, 

four  major  factors  should  be  considered: 

•  Meeting  needs 

•  Company  experience 

•  User  friendly  software 

•  Vendor  user-friendly 
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V.     NETWORKING  REQUIREMENTS 

A.     TELECOMMUNICATIONS  INFRASTRUCTURE 
1.     COMMUNICATIONS  STRUCTURE 

The  objective  of  the  EDI  system  is  to  enter  specific  EDI  trans- 
action data  once  and  then  transmit  that  data  in  a  computer  readable 
format  throughout  the  complete  EDI  cycle.  Four  approaches  for 
computer-to-computer  transfer  of  EDI  transaction  are  described  below 

and  illustrated  in  Figure  22  [Ref.  4:  p.  68]. 

•  Mail  or  courier  service  delivering  magnetic  tape  or  diskette:  Primary 
considerations  of  this  method  might  be  cost  of  transport,  security  of 
connection,  and  speed  of  delivery. 

•  Point-Point  connection  between  partners:  Both  partners  accommo- 
date the  same  communication  protocols  and  ANSI  X12  format. 
Some  considerations  are  cost  of  connection  justified  by  volume  of 
data,  and  speed  of  delivery. 

•  Value  added  network  without  translation:  It  provides  mailbox  service 
for  both  partners,  accommodating  ANSI  X12  formats.  Specific 
considerations  include: 

■    Easy    adaptation    of   each    partner's    own    line    speed,    protocol, 
multi-destination,  time  of  day,  etc. 

•  Value-added  network  with  translation:  It  provides  mailbox  and  X12 
standard  translation.  Partners  do  not  have  to  worry  about  translating 
standard  formats,  or  do  they  negotiate  line  speeds,  protocols,  multi- 
destinations,  and  times  of  day. 
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Figure  22.      Approach  for  computer-to-computer  transfer 


A  starting  point  for  determining  the  most  suitable  communications 
services  is  to  decide  where  in  the  organization  the  EDI  application  will 
be  operated  and  who  the  end  user  will  be.  Invoice  keying,  order  entry, 
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just-in-time  purchase,  stock  updating,  delivery,  customs  and  excise  no- 
tification, and  EFT  (Electronic  Funds  Transfer)  may  occur  in  different 
departments  staffed  by  different  users.  Four  scenarios  are  examined  to 
indicate  the  data  communications  options  a  company  might  adopt  when 
introducing  EDI.  They  are  referred  to  as  Integrated-External  and 
Integrated-Internal  (where  applications  require  connection  to  the  main 
process  of  the  company  in  order  for  EDI  to  function)  and  Partitioned- 
External  and  Partitioned-Internal.  The  partitioned  scenarios  are  situ- 
ations where  the  EDI  requirement  applies  to  one  end-user  department  for 
document  exchange  outside  the  company.  The  most  suitable  network 
solution  and  most  appropriate  protocols  will  be  different  for  each  of  these 
scenarios  [Ref.  5:  p.  156]. 

a.  Integrated-Internal  network  structure 
The  corporate  network  is  already  in  place.  The  existing  network 
would,  typically,  be  based  on  a  centralized  star  network  configuration 
possibly  with  multiplexing  or  a  peer-to-peer  communications  service 
based  on  a  switched  network  configuration.  Examples  of  these  config- 
urations are  SNA  networks  and  X.25  packet  switching  networks,  respec- 
tively. 
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b.  Integrated-External  network  structure 

As  with  the  internal  structure,  a  corporate  network  is  in  place. 
External  communications  are  also  set  up,  perhaps  bilaterally  on  private 
circuits  or  via  PPSN  (Public  Packet  Switched  Network).  The  need  for 
scheduling  processing  of  documents  will  dictate  the  use  of  a  store-and- 
collect  facility  which  will  typically  be  an  external  mailbox  system.  Inte- 
grated structures  should  consider  all  permanent  external  applications 
(EDIamong  them)  so  as  to  achive  economies  of  scale.  A  PPSN  with  X.25 
interfaces,  which  offers  the  exchange  of  transactions  securely  to  and  from 
the  company  to  more  than  one  destination,  best  provides  this  sort  of  ex- 
ternal network  connection. 

c.  Partitioned-lnternal  network  structure 

This  situation  is  a  point-to-point  requirement,  typically  PC  to 
mainframe.  The  cheapest  way  of  setting  this  up  is  by  using  the  PSTN 
(Public  Switched  Telephone  Network)  as  an  adjunct  to  the  mainframe's 
network  ports,  or  a  LAN  where  this  exists.  If  volumes  are  high  or  security 
considerations  rule  out  the  PSTN,  a  private  circuit  connection  to  the 
corporate  network  will  be  required. 
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d.     Partitional-External  network  structure 
This  is  a  simple  configuration  requiring  no  connection  to  the 
corporate  network.  The  EDI  application  is  likely  to  be  developed  on  a 
PC  and  external  communications  will  probably  be  via  the  PSTN  to  the 
EDI  clearing  house  or  correspondent. 
2.    PROTOCOLS 

The  main  types  of  protocol  and  their  suitability  for  an  EDI  com- 
munications service  are  considered  first.  Protocols  in  this  instance  refer 
to  the  station-to-station  procedures  for  handling  the  correct  transmission 
of  data  across  a  link  and  the  data  stream.  The  main  protocols  relevant 
to  EDI  are  given  below  [Ref.  10:  p.  26]. 
a.  3780  and  2780 
These  are  block-mode  protocols  used  for  one  way  at  a  time 
(half  duplex)  exchange  of  data  in  batch.  Commonly  referred  to  as  Remote 
Job  Entry  (RJE)  they  are  used  between  processes-PC  to  mainframe,  de- 
partmental mini  system  to  mainframe.  Partitioned  network  structures  will 
find  this  method  most  suitable  as  it  offers  a  widely  available  means  of 
transmitting  files  error-corrected  over  the  PSTN.  The  characteristics  of 
the  files  are  likely  to  be  low  volumes  "of  data  generated  in  a  stand-alone 
PC.  Most  communications  hardware  suppliers  support  these  protocols. 
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They  have  been  established  for  many  years  and  they  originate  from  the 
early  IBM  data  processing  environment. 

b.  3270  and  3770 

Whereas  2780/3780  is  the  de  facto  batch  protocol  from  the  BSC 
environment,  3270  is  the  de  facto  screen  display  data  stream.  It  is  nearly 
always  associated  with  SNA/SDLC  (Systems  Network  Architecture/  Syn- 
chronous Data  Link  Control).  SDLC  is  the  link  level  transport  mech- 
anism, usually  point-to-point  cluster  controller  to  FEP  (Front  End 
Processor),  supporting  and  protecting  the  integrity  of  the  3270  data 
stream  across  the  link.  3770  is  used  for  batch  work  in  the  SNA  environ- 
ment. When  the  network  structure  fits  the  integrated  network  scenarios, 
3270  and  SDLC  are  appropriate. 

c.  VT100,  TTY  and  C03 

In  very  many  processes,  documents  are  exchanged  interactively 
by  an  operator  or  admin  clerk  filling  in  forms  on  a  workstation  attached 
locally  or  remotedly  to  a  host  system.  In  addition  to  3270,  C03  and 
Screen  VT100  apply.  C03  is  similar  to  3270/SDLC  in  concept  and  exists 
in  the  ICL  (International  Computers  Limited)  environment.  VT100  is  a 
character-interrupt  protocol  and  is  usually  restricted  to  terminals  which 
are  directly  attached  to  a  DEC  host  system. 
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d.  X.25 
The  X.25  protocol  is  the  standard  method  of  interfacing  to 
packet  networks.  It  is  made  up  of  three  levels:  the  physical  or  line  level 
where  the  control  of  the  electrical  interface  is  defined  (V.24,  V.35  and 
X.21bis);  the  link  level  which,  with  HDLC,  ensures  that  data  is  trans- 
ported across  a  link  with  integrity  and  under  the  control  of  both  ends  of 
the  link;  and  the  packet  level  where  data  is  split  into  packets  and  are  dy- 
namically multiplexed  such  that  many  calls  to  many  addresses  can  be 
transported  simultaneously  on  a  single  link.  X.25  defines  the  interface 
between  DTE  (Data  Terminal  Equipment)  and  the  packet  switch.  The 
manner  in  witch  data  is  handled  within  a  network  is  not  merely  a  function 
of  the  X.25  protocol  but  the  design  of  the  network  itself.  X.25  is  suitable 
for  the  integrated  network  structure  scenarios  where  corporate  communi- 
cations are  based  on  X.25.  Partitioned  network  structures  can  also  6pt  for 
X.25  because  the  protocol  is  firmly  supported  by  PC  communication  card 
manufacturers  as  well  as  all  the  main  data  processing  officer  automation 
equipment  manufactures  [Ref.  5:  p.  159]. 
3.     NETWORKS 

More  significant  than  the  protocol  is  the  network  which  is  to  be 
selected  for  EDI.  This  is  because  the  selection  can  involve  investment 
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decisions  which  are  far  more  important,  particularly  for  the  integrated 
network  structures.  In  selecting  the  appropriate  type  of  networking  for 
EDI,  the  breadth  of  applications  which  the  network  is  required  to  carry 
needs  to  be  considered.  EDI  is  usually  going  to  be  only  one  of  many  ap- 
plications in  an  organization. 

a.  Separating  the  functions 

The  relationship  between  the  EDI  application  and  the  trans- 
port network  should  be  considered  case-by-case  when  deciding  which  EDI 
solution  to  adopt.  The  functions  which  the  EDI  application  provide  and 
the  network  needed  to  connect  the  application  are  conceptually  inde- 
pendent. The  EDI  application  is  a  processing  problem— that  of  conver- 
sion, storage,  collection,  and  auditing.  The  network  is  an  infrastructure 
problem,  the  bearer  of  a  wide  variety  of  applications,  economic  wide  area 
access,  and  where  needed,  routing,  resilience,  multiplexing,  switching,  and 
data  stream  and  protocol  conversion. 

b.  Network  management 

A  good  network  management  and  maintenance  operation  is 
essential  to  sustain  a  high  quality  of  service.  This  applies  to  any  data 
network  which  is  capable  of  providing  the  communications  infrastructure 
for  a  company's  internal  and  external  networking  needs.  This  is  the  area 
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which  requires  the  most  expense  in  skills.  The  cost  of  doing  this  often 
outweighs  the  capital  investment  of  the  equipment  in  the  network.  The 
EDI  User  should  where  possible  take  a  advantage  of  third  party  service 
because  the  financial  structure  of  the  business  may  not  afford  the  wide 
area  network  investment  and  running  cost.  The  other  significant  issue  in 
deciding  whether  a  third  party  EDI  service  provider  has  the  appropriate 
network  solution  for  the  company  who  wants  to  integrate  external  EDI 
within  his  company  (the  integrated-extemal  scenario)  is  the  extent  of  ge- 
ographic coverage  provided  by  that  third  party  service  provider. 
c.  Public  and  Private  network 
One  of  the  main  determining  factors  when  deciding  between 
public  and  private  networks  is  the  cost.  It  is  often  actually  cheaper  to 
use  a  Public  Data  Network  than  for  the  company  to  build  the  network 
for  itself.  This  is  especially  so  when  all  related  costs  are  included;  that  is 
to  say,  all  equipments  including  network  management  tools,  skilled  staff 
resource,  and  all  reased  items  such  as  private  circuits.  As  an  example,  the 
comparison  for  a  22-site  network  spread  nationally  is  shown  in  Figure  23 
[Ref.  5:  p.  161].  Costs  of  using  the  Public  Data  Network  comprise  con- 
nection charge  and  quarterly  rental  for  each  data  line  (direct  connection) 
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from  the  customer's  equipment.   A  list  and  a  visual  representation  of  the 
main  Public  Data  Network  services  is  shown  in  Figure  24  [Ref.  5:  p.  163]. 


B.     USE  OF  THIRD  PARTY  NETWORKS 


Third  party  networks  are  not  used  by  all  organizations  that  have  im- 
plemented EDI.  However,  recent  estimates  place  the  percentage  of  or- 
ganizations that  have  implemented  EDI  and  are  currently  using  third 
party  networks  at  approximately  60  percent  of  all  EDI  users.  While  it 
might  seem  logical  that  large  organizations  would  be  the  least  likely  to 
use  third  party  network  services,  approximately  75  percent  of  the  Fortune 
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500  companies  who  perform  EDI  use  third  party  networks  to  some  extent. 
Further,  as  the  use  of  EDI  continues  to  expand,  the  use  of  third  party 
networks  is  also  expected  to  expand.  Most  of  the  growth  in  EDI  is  likely 
to  come  from  the  implementation  of  EDI   by  small  and   middle-sized 
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companies  as  their  larger  trading  partners  begin  to  demand  EDI  trans- 
actions. Many  of  these  companies  do  not  believe  that  they  have  the  in- 
house  resources  and  skills  necessary  to  establish  direct  EDI  linkages  with 
trading  partners.  Further,  even  in  organizations  where  resources  are 
available,  many  organizations  have  found  that  the  use  of  a  third  party 
network  relieves  much  of  the  systems  development  burden. 

There  appear  to  be  a  number  of  key  issues  that  require  consideration 
by  organizations  considering  the  use  of  third-party  Value  Added  Net- 
works or  a  third-party  network  in  particular  [Ref.  4:  p.  77]. 

The  first  issue  is  whether  to  use  a  third-party  network.  The  answer  is 
primarily  dependent  on  the  firm's  systems  experience,  transaction  volumes 
(overall  and  between  buyer  and  seller)  and  current  and  future  states  of 
your  firm's  computer  hardware.  With  an  experienced  firm  with  signif- 
icant hardware,  direct  computer-to-computer  links  with  selected  key  sup- 
pliers may  be  appropriate.  For  the  largest  multitude  for  firms,  it  appears 
that  the  use  of  a  third-party  network  for  EDI  may  be  most  appropriate. 
Once  the  decision  to  use  a  third-party  network  is  made,  then  the  decision 
criteria  discussed  can  be  applied.  There  are  a  few  most  significant  issues 
that  become  critical  when  selecting  a  specific  third  party  provider.  First, 
it  is  important  to  determine  that  the  provider  has  both  the  commitment 
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and  financial  resources  to  stay  in  business.  It  is  essential  that  they  provide 
continuity  and  continuous  system  enhancements. 

Secondly,  it  is  imperative  that  the  third  party  provider  has  the  capa- 
bility of  gateway  to  other  third  parties.  It  is  important  that  the  provider 
has  two-way  access  to  other  third  parties  being  used  by  the  suppliers  (and 
customers)  to  guarantee  a  smooth  flow  of  data.  Figure  25  [Ref.  4:  p.  78] 
identifies  a  number  of  third-party  Value  Added  Network  providers  and 
lists  who  they  gateway  with  (as  reported  by  the  third-party  networks 
themselves). 

Thirdly,  it  is  important  that  the  third-party  be  able  to  do  business  on 
a  worldwide  basis,  if  your  firm  is  a  global  participant.  The  need  to 
interface  with  foreign  suppliers  is  an  important,  if  not  more  so,  than  with 
domestic  firms. 

Fourthly,  your  firm  and  the  third-party  should  be  active  in  furthering 
development  and  acceptance  of  inter-industry  standards  such  as  ANSI 
XI 2.  Further  development  and  refinement  of  these  standards  is  extremely- 
important  to  EDI  and  to  fostering  electronic  communications. 

Finally,  the  third-party  network  should  be  working  with  other  kinds 
of  organizations  such  as  financial  institutions,  trading  companies,  trans- 
portation firms  and  so  forth.  This  will  increase  the  likelihood  of  devel- 
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oping  electronically  integrated  purchasing,  man     xturing,  transportation 
and  financial  systems,    the  firm  should  then  be  able  to  benefit  from  any 


innovations. 
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VI.      AUDITING  AND  SECURITY  ISSUES 

A.     AUDITING 

In  any  EDI  system,  managers  need  to  substantiate  that  the  system  is 
processing  information  correctly.  This  substantiation  is  provided  by  the 
capability  to  track  any  transaction  to  its  closing.  This  physical  tracking 
of  a  transaction  through  the  system  is  called  the  audit  trail.  Since  the 
audit  trail  is  a  primary  source  of  information  for  purchasing  profes- 
sionals, it  is  imperative  that  an  adequate  trail  be  available  to  them  for 
verification  purposes.  In  the  EDI  environment,  the  record  of  purchasing 
transactions  between  the  buyer  and  suppiler  is  electronic  rather  than  pa- 
per based.  This  change  to  electronic  documentation  impacts  the  manner 
in  which  the  purchasing  function  controls  the  buying  process. 

The  degree  to  which  the  EDI  system  impacts  the  purchasing  control 
process  depends  primarily  on  the  level  of  sophistication  of  the  EDI  sys- 
tem. Physical  documents  such  as  manufacturing  order  releases,  invoices, 
advance  shipping  notices,  and  bills  of  lading  continue  to  exist  and  can 
be  used  as  check  mechanisms.  As  more  vendors  and  document  types  are 
added  to  the  EDI  system,  effective  auditing  and  control  procedures  need 
to  be  designed  into  the  system.  With  effective  planning,  controlling  the 
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EDI  system  is  relatively  painless.    Several  elements  are  needed  for  the  cost 

effective  control  of  an  EDI  system.  Those  include: 

•  Well  defined  and  clearly  written  job  procedures. 

•  A  systems  user  guide  that  parallels  and  complements  the  job  proce- 
dures. 

•  Systems  technical  documentatin. 

•  A  well-run  data  center.    [Ref.  11:  p.  23] 

The  amount  of  time,  effort,  and  resources  placed  on  designing  an  ef- 
fective EDI  control  system  depends  upon  the  level  of  sophistication  of  the 
particular  firm's  EDI  and  automated  purchasing  system.  The  procure- 
ment manager  must  understand  the  auditing  and  control  issues  created 
by  the  use  of  an  EDI  system.  The  manager  must  have  a  knowledge  of  the 
function  and  use  of  these  control  mechanisms.  The  emphasis  when  de- 
signing procedures  of  the  EDI  system  should  be  on  the  day-to-day  control 
of  the  system.  The  control  procedures  must  be  good  enough  so  that  any 
kind  of  discrepancies  that  arise  can  be  resolved  and  legal  requirements 
satisfied. 

The  EDI  system  must  address  the  system  concerns  of  auditing.  It  is 
important  to  involve  auditing  in  the  EDI  planning  and  implementation 
process.  Effective  system  auditing  and  storage  procedures  can  only  be  ef- 
fectively built  in  early  in  the  EDI  system  design  and  implementation 
processes.    The  type  and  nature  of  control  mechanism  should  be  deter- 
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mined  jointly  by  purchasing  and  auditing.  Many  of  these  controls  must 
be  designed  into  the  EDI  system  before  the  system  is  placed  on-line. 
Adding  control  mechanisms  after  the  system  is  in  operation  is  costly  and 
could  affect  the  cost-effective  functioning  of  the  EDI  system. 

Auditing,  although  an  important  issue,  can  be  successfully  managed. 
The  issues  and  concerns  can  be  systematically  addressed.  It  is  incumbent 
upon  every  professional  user  of  the  EDI  system  to  ensure  that  the  system 
is  performing  as  intended.  Auditing  issues  must  be  addressed  early  in  the 
EDI  implementation.  Auditors  have  been  dealing  with  electronic  data 
processing  systems  for  years.  They  must  utilize  the  knowledge  of  auditors 
in  designing  and  implementing  the  EDI  system  controls. 

B.     SECURITY 

The  security  of  electronic  data  is  a  continuing  managerial  problem. 
Security  issues  for  other  internal  computerized  systems  have  many  of  the 
same  characteristics  as  those  associated  with  EDI  systems.  Security  issues 
involving  EDI  should  be  viewed  as  an  extension  of  current  security  issues, 
procedures,  and  standards  which  many  organizations  have  already  ad- 
dressed with  other  computerized  systems  [Ref.  4:  p. 48]. 

The  major  difference  between  EDI  and  puchasing  system  security  is 
that  persons  external  to  the  organization  are  involved.    Vital  information 
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concerning  pricing,  contracts,  quotes,  and  purchase  orders  are  routinely 
transmitted  electronically  in  the  EDI  environment.  It  is  imperative  that 
this  information  be  secure  and  accessed  by  only  authorized  parties. 
Problems  such  as  sending  a  purchase  order  to  the  wrong  supplier  must 
be  avoided.  Without  proper  monitoring  and  technological  safeguards, 
information  could  accidentally  or  deliberately  be  made  available  to  the 
wrong  party. 

EDI  security  systems  are  required  because  information  has  value.  The 
protection  of  the  purchasing  data  base  and  maintaining  the  integrity  of 
the  data  transmitted  are  the  goals  of  the  security  system.  Access  re- 
strictions should  be  established  by  policy  and  enforced  by  written  stand- 
ards and  procedures. 

Protective  security  measures  are  built  into  each  of  three  security  ele- 
ments. First.  Physical  security  measures  restrict  physical  access  to  the 
system.  Examples  include  locked  doors,  keys,  guards,  alarms,  etc.  Second, 
procedural  security  measures  provide  controls  over  authorization  to  see 
or  use  information.  Examples  include  authorized  employee  lists,  infor- 
mation elements  access  approval,  passwords,  and  separation  of  duties. 
Third,  logical  security  measures  restrict  access  to  information  in  electronic 
forms.  Examples  include  software  systems  which  implement  access  control 
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through  the  use  of  fingerprint  recognition,  voice  recognition,  and  data 
transformation  and  encryption.  In  a  technologically  complex  system, 
protection  often  requires  a  combination  of  all  three  security  elements. 

Management  should  first  subjectively  and  objectively  look  at  the  na- 
ture of  the  information  involved  in  the  EDI  transfer.  Security  standards 
should  directly  reflect  the  value  and  sensitivity  of  the  information.  For 
information  that  is  of  high  value  to  the  organization,  stringent  security 
standards  should  be  implemented. 

A  well-designed  security  system  ensures  information  availability  to 
authorized  user  personnel,  but  at  the  same  time  protects  the  integrity  of 
the  data  and  the  system.  EDI  security  should  be  viewed  as  protection  of 
the  purchasing  data  base,  the  physical  hardware,  and  the  transmitted  data. 
Security  concerns  occur  through  the  entire  EDI  system,  therefore  EDI 
security  must  address  both  the  external  as  well  as  internal  environment. 
Identifying  potential  problem  areas  before  the  EDI  system  is  put  on-line 
will  aid  in  the  design  of  a  fully  protected  system.  Figure  26  [Ref.  4:  p. 50] 
presents  the  information  flow  from  initial  data  base  creation  through  in- 
formation dispersion  to  the  supplier  network.  All  nodes  and  links  of  this 
system  should  be  carefully  analyzed  for  security. 
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Figure  26.      Threats  from  transaction  of  data  from  nodes 
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VII.     CONCLUSION 

EDI  is  headed  up  in  terms  of  volume  of  usage  and  is  headed  in  in 
terms  of  integration  with  other  management  concepts  and  technnologies. 
Exponential  growth  is  expected  in  EDI  usage  in  the  next  few  years.  It  is 
predicted  that  by  1993  over  70  percent  of  U.S.  firms  will  be  making  sig- 
nificant use  of  EDI.  By  1995,  over  400,000  companies  worldwide  will  be 
communicating  electronically.  The  growth  is  expected  to  come  from  a 
number  of  directions.  The  United  States  is  currently  ahead  of  all  other 
countries  in  terms  of  level  of  EDI  use.  However,  other  areas  of  the  world 
are  begining  to  catch  up.  Major  EDI  efforts  are  underway  in  Canada, 
Western  Europe,  the  Pacific  rim,  and  the  Soviet  Bloc,  as  well  as  in  other 
parts  of  the  world.  One  estimate  places  the  annual  growth  rate  of  EDI 
worldwide  at  about  88  percent  a  year  over  the  next  three  years  [Ref.  12: 
p.  67-73]. 

EDI  also  going  to  expand  out.  New  and  different  applications  of  EDI 
will  be  used.  Currently,  EDI  is  used  for  the  communication  of  standard 
business  documentation  in  a  structured  format.  The  communication  is 
done  using  EDI  standards  and  EDI  networks.  However,  much  of  what 
is  communicated  in  business  does  not  fit  that  category.  Electronic  mail, 
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voice  imaging,  and  videotext  are  currently  being  used  to  some  degree  for 
business  communications.  It  is  expected  that  EDI  technology  will  even- 
tually expand  to  allow  for  the  incorporation  of  such  communications 
methods.  EDI  does  not  provide  for  the  communication  of  drawings  or 
graphics  since  these  do  not  fit  a  standard  structured  format.  However,  the 
expansion  of  EDI  to  incorporate  such  items  appears  to  be  underway,  as 
evidenced  in  CALS.  At  least  one  software  supplier  has  announced  that 
its  EDI  software  can  be  used  for  the  transmission  of  engineering  drawing 
and  graphics  in  CAD/CAM  format. 

EDI  has  become  an  accepted  and  fairly  standard  method  of  commu- 
nication within  the  auto  industry,  more  efforts  are  being  undertaken  to 
closely  integrate  EDI  within  internal  systems,  including  JIT  scheduling, 
information  systems  and  Common  Manufacturing  Management  Systems 
(CMMS). 

Legal  considerations  were  seen  as  the  major  obstacle  to  implementing 
EDI.  Terms  and  conditions  which  legally  serve  to  bind  and  protect  the 
buyer  and  seller  would  no  longer  accompany  each  purchase  order  under 
electronic  transmission.  Legal  counsel  can  alleviate  this  obstacle  by 
drafting  blanket  agreements  covering  all  responsibilities  and  obligations 
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of  the  buyer  and  seller.  This  agreement  needs  to  be  signed  by  both  parties 
prior  to  broad-scale  EDI  start-up  [Ref.  13:  p.  25]. 

Another  concern  involving  EDI  implementation  is  the  security  issues 
associated  with  transmission  of  business  information  through  an  external 
network.  Information  has  value  and  must  be  protected.  Internally  infor- 
mation is  protected  via  password  or  authorization  codes.  The  safeguards 
that  exist  internally  are  also  available  for  use  in  the  networking  environ- 
ment. Before  selecting  a  vendor  who  provides  networking  services,  a 
thorough  evaluation  of  their  security  methods  must  be  conducted. 

EDI  will  be  essential  to  the  procurement  process  making  a  key  con- 
tribution to  the  firm's  competitive  advantage.  EDI  plays  an  important 
role  in  the  procurement  strategy  of  leading  edge  firms.  Application  of 
EDI  will  be  increasing  dramatically  in  the  future  on  a  worldwide  basis. 
Extensive  growth  of  EDI  is  on  the  near-term  horizon.  EDI  is  fast  reaching 
the  point  where  it  will  become  a  requirement  to  do  business.  Significant 
benefits,  in  the  form  of  reduced  costs,  improved  productivity,  and  better 
information,  result  from  EDI. 
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